home *** CD-ROM | disk | FTP | other *** search
/ NeXTSTEP 3.3 (Developer)…68k, x86, SPARC, PA-RISC] / NeXTSTEP 3.3 Dev Intel.iso / NextDeveloper / Headers / mach-o / reloc.h < prev    next >
C/C++ Source or Header  |  1994-10-05  |  8KB  |  154 lines
  1. /*
  2.  * Copyright (c) 1980 Regents of the University of California.
  3.  * All rights reserved.  The Berkeley software License Agreement
  4.  * specifies the terms and conditions for redistribution.
  5.  *
  6.  *    @(#)a.out.h    5.1 (Berkeley) 5/30/85
  7.  *
  8.  * The structure this file describes was originally taken from the above file
  9.  * and the above copyright has been carried over to this file.
  10.  */
  11.  
  12. #ifndef _MACHO_RELOC_H_
  13. #define _MACHO_RELOC_H_
  14.  
  15. /*
  16.  * Format of a relocation entry of a Mach-O file.  Modified from the 4.3BSD
  17.  * format.  The modifications from the original format were changing the value
  18.  * of the r_symbolnum field for "local" (r_extern == 0) relocation entries.
  19.  * This modification is required to support symbols in an arbitrary number of
  20.  * sections not just the three sections (text, data and bss) in a 4.3BSD file.
  21.  * Also the last 4 bits have had the r_type tag added to them.
  22.  */
  23. struct relocation_info {
  24.    long        r_address;    /* offset in the section to what is being
  25.                    relocated */
  26.    unsigned int r_symbolnum:24,    /* symbol index if r_extern == 1 or section
  27.                    ordinal if r_extern == 0 */
  28.         r_pcrel:1,     /* was relocated pc relative already */
  29.         r_length:2,    /* 0=byte, 1=word, 2=long */
  30.         r_extern:1,    /* does not include value of sym referenced */
  31.         r_type:4;    /* if not 0, machine specific relocation type */
  32. };
  33. #define    R_ABS    0        /* absolute relocation type for Mach-O files */
  34.  
  35. /*
  36.  * The r_address is not really the address as it's name indicates but an offset.
  37.  * In 4.3BSD a.out objects this offset is from the start of the "segment" for
  38.  * which relocation entry is for (text or data).  For Mach-O object files it is
  39.  * also an offset but from the start of the "section" for which the relocation
  40.  * entry is for.
  41.  * 
  42.  * In 4.3BSD a.out objects if r_extern is zero then r_symbolnum is an ordinal
  43.  * for the segment the symbol being relocated is in.  These ordinals are the
  44.  * symbol types N_TEXT, N_DATA, N_BSS or N_ABS.  In Mach-O object files these
  45.  * ordinals refer to the sections in the object file in the order their section
  46.  * structures appear in the headers of the object file they are in.  The first
  47.  * section has the ordinal 1, the second 2, and so on.  This means that the
  48.  * same ordinal in two different object files could refer to two different
  49.  * sections.  And further could have still different ordinals when combined
  50.  * by the link-editor.  The value R_ABS is used for relocation entries for
  51.  * absolute symbols which need no further relocation.
  52.  */
  53.  
  54. /*
  55.  * For RISC machines some of the references are split across two instructions
  56.  * and the instruction does not contain the complete value of the reference.
  57.  * In these cases a second, or paired relocation entry, follows each of these
  58.  * relocation entries, using a PAIR r_type, which contains the other part of the
  59.  * reference not contained in the instruction.  This other part is stored in the
  60.  * pair's r_address field.  The exact number of bits of the other part of the
  61.  * reference store in the r_address field is dependent on the particular
  62.  * relocation type for the particular architecture.
  63.  */
  64.  
  65. /*
  66.  * To make scattered loading by the link editor work correctly "local"
  67.  * relocation entries can't be used when the item to be relocated is the value
  68.  * of a symbol plus an offset (where the resulting expresion is outside the
  69.  * block the link editor is moving, a blocks are divided at symbol addresses).
  70.  * In this case. where the item is a symbol value plus offset, the link editor
  71.  * needs to know more than just the section the symbol was defined.  What is
  72.  * needed is the actual value of the symbol without the offset so it can do the
  73.  * relocation correctly based on where the value of the symbol got relocated to
  74.  * not the value of the expression (with the offset added to the symbol value).
  75.  * So for the NeXT 2.0 release no "local" relocation entries are ever used when
  76.  * there is a non-zero offset added to a symbol.  The "external" and "local"
  77.  * relocation entries remain unchanged.
  78.  *
  79.  * The implemention is quite messy given the compatibility with the existing
  80.  * relocation entry format.  The ASSUMPTION is that a section will never be
  81.  * bigger than 2**24 - 1 (0x00ffffff or 16,777,215) bytes.  This assumption
  82.  * allows the r_address (which is really an offset) to fit in 24 bits and high
  83.  * bit of the r_address field in the relocation_info structure to indicate
  84.  * it is really a scattered_relocation_info structure.  Since these are only
  85.  * used in places where "local" relocation entries are used and not where
  86.  * "external" relocation entries are used the r_extern field has been removed.
  87.  *
  88.  * For scattered loading to work on a RISC machine where some of the references
  89.  * are split across two instructions the link editor needs to be assured that
  90.  * each reference has a unique 32 bit reference (that more than one reference is
  91.  * NOT sharing the same high 16 bits for example) so it move each referenced
  92.  * item independent of each other.  Some compilers guarantees this but the
  93.  * compilers don't so scattered loading can be done on those that do guarantee
  94.  * this.
  95.  */
  96. #if defined(__BIG_ENDIAN__) || defined(__LITTLE_ENDIAN__)
  97. /*
  98.  * The reason for the ifdef's of __BIG_ENDIAN__ and __LITTLE_ENDIAN__ are that
  99.  * when stattered relocation entries were added the mistake of using a mask
  100.  * against a structure that is made up of bit fields was used.  To make this
  101.  * design work this structure must be laid out in memory the same way so the
  102.  * mask can be applied can check the same bit each time (r_scattered).
  103.  */
  104. #endif /* defined(__BIG_ENDIAN__) || defined(__LITTLE_ENDIAN__) */
  105. #define R_SCATTERED 0x80000000    /* mask to be applied to the r_address field 
  106.                    of a relocation_info structure to tell that
  107.                    is is really a scattered_relocation_info
  108.                    stucture */
  109. struct scattered_relocation_info {
  110. #ifdef __BIG_ENDIAN__
  111.    unsigned int r_scattered:1,    /* 1=scattered, 0=non-scattered (see above) */
  112.         r_pcrel:1,     /* was relocated pc relative already */
  113.         r_length:2,    /* 0=byte, 1=word, 2=long */
  114.         r_type:4,    /* if not 0, machine specific relocation type */
  115.            r_address:24;    /* offset in the section to what is being
  116.                    relocated */
  117.    long        r_value;    /* the value the item to be relocated is
  118.                    refering to (without any offset added) */
  119. #endif /* __BIG_ENDIAN__ */
  120. #ifdef __LITTLE_ENDIAN__
  121.    unsigned int
  122.            r_address:24,    /* offset in the section to what is being
  123.                    relocated */
  124.         r_type:4,    /* if not 0, machine specific relocation type */
  125.         r_length:2,    /* 0=byte, 1=word, 2=long */
  126.         r_pcrel:1,     /* was relocated pc relative already */
  127.         r_scattered:1;    /* 1=scattered, 0=non-scattered (see above) */
  128.    long        r_value;    /* the value the item to be relocated is
  129.                    refering to (without any offset added) */
  130. #endif /* __LITTLE_ENDIAN__ */
  131. };
  132.  
  133. /*
  134.  * Relocation types used in a generic implementation.  Relocation entries for
  135.  * nornal things use the generic relocation as discribed above and their r_type
  136.  * is GENERIC_RELOC_VANILLA (a value of zero).
  137.  *
  138.  * The other type of generic relocation, GENERIC_RELOC_SECTDIFF, is to support
  139.  * the difference of two symbols defined in different sections.  That is the
  140.  * expression "symbol1 - symbol2 + constant" is a relocatable expression when
  141.  * both symbols are defined in some section.  For this type of relocation the
  142.  * both relocations entries are scattered relocation entries.  The value of
  143.  * symbol1 is stored in the first relocation entry's r_value field and the
  144.  * value of symbol2 is stored in the pair's r_value field.
  145.  */
  146. enum reloc_type_generic
  147. {
  148.     GENERIC_RELOC_VANILLA,    /* generic relocation as discribed above */
  149.     GENERIC_RELOC_PAIR,        /* Only follows a GENRIC_RELOC_SECTDIFF */
  150.     GENERIC_RELOC_SECTDIFF
  151. };
  152.  
  153. #endif /* _MACHO_RELOC_H_ */
  154.